We are currently serializing columns per-field, but in case of late
column extension this might result in inconsistent sorting of the columns
in the serialized footer.

e.g. assume you have fields "A" and "B", both late model extended, both
with a single column:
    - col 0 -> field A, repr 0
    - col 1 -> field B, repr 0

Now you add a new column representation to field "A"; this new column
has id 2:
    - col 2 -> field A, repr 1

When serializing this RNTuple, all columns are written in the footer by
RNTupleSerialize::SerializeColumnsForFields(). Before this change, they
would end up on disk in order: [0, 2, 1].
This would corrupt the data by swapping the pages for columns 2 and 1.

After this change, they get written as [0, 1, 2] which is the correct
order.

Note that this exact case is tested in ntuple_merger in the unit test
MergeDeferredAdvanced.

Two field descriptors might legitimately have different numbers of
elements in their LogicalColumnIds vectors due to having a different
number of representations.

The proper check to do is the one on the column cardinality, which
makes sure that the same number of columns is actually used at a time.

This test checks two things:

1. that the fix applied by 14ade04 works
   properly (this is already checked by MergeDeferredAdvanced but that
   might not be the case anymore if we update the merger to change the
   column encodings depending on the output compression - in which case
   that test would not be adding a late extended column anymore);
2. that the merger properly handles fields with the same cardinality
   but different number of column representations

…ation

Also set the anchor version in InitFromDescriptor().

clarify that it is only valid for the 0th representation index